In many countries operators and Internet service providers are today obliged by legal requirements to provide stored traffic data generated from public telecommunications and Internet services for the purpose of detection, investigation and prosecution of crime and criminal offences, including terrorism.
There are also a number of initiatives within the European Union (EU) to regulate the legal basis for data retention. The EU Parliament adopted a set of amendments and by that approved the Council's proposed directive on data retention (Directive 2006/24/EC). In this directive, initial requirements and how an extension of the directive will be handled are described. Consequently, an essential part of operator's effort to comply with current legislation is to secure that processes and tools can be adapted to handle an expansion of the scope for data retention.
Technical specification ETSI DTS/LI-00039 gives guidance for the delivery and associated issues of retained data of telecommunications and subscribers. In particular, ETSI DTS/LI-00039 provides a set of requirements relating to Handover Interfaces for the retained traffic data and subscriber data by law enforcement and other authorized requesting authorities. The requirements are to support implementation of Directive 2006/24/EC of the European Parliament and of the Council of 15 Mar. 2006 regarding the retention of data. Technical Specification ETSI DTS/LI-00033 contains handover requirements and a handover specification for the data that is identified in EU Directive 2006/24/EC on retained data.
FIG. 1 depicts the known arrangement for retaining data in a Communication Service Provider 1 (CSP). Specifically, the CSP 1, which may incorporate existing communication systems 2, is provided with a Data Retention System (DRS) 3 for exchanging retained data relating information with a Requesting Authority 4, which may be a Law Enforcement Agency (LEA).
The data exchanged between the CSP 1 and the Requesting Authority 4 comprises requests from the Requesting Authority 4, corresponding responses from the DRS and other DR information, such as results of the requests and acknowledgements of receipt. The interfaces through which the CSP and DRS exchange the above data with the Requesting Authority are denoted as Handover Interfaces.
The generic Handover Interface adopts a two-port structure in which administrative request/response information and Retained Data Information are logically separated. In particular, a first Handover Interface port HI-A 5 is configured to transport various kinds of administrative, request and response information from/to the Requesting Authority 4 and an organization at the CSP 1 that is responsible for Retained Data matters, identified by an Administration Function 7.
A second Handover Interface HI-B 6 is configured to transport the retained data information stored in a repository 9 from the CSP 1 to the Requesting Authority 4. The individual retained data parameters have to be sent to the Requesting Authority 4 at least once (if available). To this aim, a Mediation/Delivery function 8 is provided, for retrieving the retained data from the memory means 9 and forward such data to the Requesting Authority 4 in a suitable format through the HI-B 6.
A second system for accessing communications related data is the well-known Lawful Interception (LI) system, which is depicted in FIG. 2. The standard architecture 10 comprises an Intercepting Control Element (ICE) 11 providing the user equipment of the target user with an access to the telecommunications network. An ICE may be, for instance, a 3G Mobile service Switching Center (MSC) Server, a 3G Gateway MSC Server, a Serving GPRS Support Node (SGSN), or a Gateway GSN (GGSN).
The architecture 10 further comprises one or more Law Enforcement Monitoring Facilities (LEMFs) 12 through which respective LEAs receive interception information.
An Administration Function (ADMF) entity 13 is further configured for sending the target identity and LI authorization data from the LEAs to the ICE. The ADMF 13 interfaces through a first Handover Interface 14 (HI1) with all the LEAs that may require interception in the intercepting network, keeps the intercept activities of individual LEAs separate and interfaces to the intercepting network. The ADMF 13 is also used to hide from the ICE 11 that there might be multiple activations by different LEAs on the same target. The ADMF 13 may be partitioned to ensure separation of the provisioning data from different agencies.
Every physical ICE 11 is linked to the ADMF by means of its own X1_1 interface. Consequently, every single ICE performs interception, i.e. activation, deactivation, interrogation as well as invocation, independently from other ICEs.
In order to deliver the intercepted information to the LEAs, two Delivery Functions (DF) entities are provided, each exchanging respective portions of information with the ADMF 13 (through X1_2 and X1_3 interfaces) and the LEMF 12.
In particular, a DF2 entity 15 is configured to receive Intercept Related Information (IRI) from the ICE, through an X2 interface, and to convert and distribute the IRI to the relevant LEAs via a second Handover Interface 16 (HI2) by means of a Mediation Function (MF) 17.
The IRI is a collection of information or data associated with telecommunication services involving the target identity, such as call associated information or data (e.g. unsuccessful call attempts), service associated information or data (e.g. service profile management by subscriber) and location information.
A DF3 entity 18, instead, is configured to receive Content of Communications (CC) information from the ICE 11 through an X3 interface, and to convert and distribute such information to the relevant LEA through an MF 19 and a third Handover Interface 20 (HI3).
The CC is information different from the IRI, which is exchanged between two or more users of a telecommunications service and, more in general, includes information which may, as part of some telecommunications service, be stored by one user for subsequent retrieval by another user.
In the most recent developments, current IP networks can be provided with a deep packet inspection feature for improving the operator's existing infrastructure with better service and subscriber awareness.
With reference to FIG. 3, the deep packet inspection function is usually implemented by a Content Analyzer element 22, present in a Service Aware Support Node 21 (SASN). SASNs perform a stateful analysis of the traffic, which enables a richer packet inspection (for example, event detection is based on this feature). When a new protocol flow is detected (for example a TCP connection) an entity is allocated in SASN to store its state and associated parameters. This entity is called an analysis flow. Several flows can exist for the same user session, one for each stateful protocol to be analyzed.
The Content Analyzer 22 is configured to parse the user incoming traffic 23, delimit the flows according to the protocol being used, and extract several parameters that are used by a traffic classification engine 24, according to configurable classification rules.
The result of the deep packet inspection is to classify raw traffic packets into a number of configurable traffic categories or Virtual Classes. Examples of traffic categories are: Web navigation to a certain site, IP traffic, FTP downloads, and so on. A Virtual Session is an entity that represents all the traffic of the same type within a user data session.
The packet analysis is the process whereby a packet is identified as belonging to certain protocols and useful information is extracted from it.
Packet analysis is performed by a Protocol Engine 24 of the Content Analyzer 22. The Protocol Engine 24 is composed of several Protocol Analyzers 25, one for each of the supported protocols. Protocol Analyzers 25 are linked with one another to build a protocol analysis stack.
The collection of parameters obtained by the analysis of one packet is referred to as the Packet Context. The Packet Context contains parameters that have been obtained by several Protocol Analyzers.
The Rule Engine 26 of the Classification Engine 29 is configured to classify the traffic packets 27 once the Protocol Engine 24 has analyzed those packets and their Packet Context has been extracted. Databases 30a, 30b, and 30c are repositories of rules used to analyze the packets.
An example of Classification Engine 29 is shown in FIG. 4. The Classification Rules are configurable combinations of packet context parameters (for example, protocol state and Uniform Resource Identifier) combined by logical operators into a Boolean expression.
The protocol fields and states that are exposed by the different protocol analyzers, can be used to create traffic classification rules 28a, 28b, 28c and can be included in Event Detail Records (EDRs).
An EDR represents the report of the deep packet inspection and contains a first set of fields which are shared by all protocol analyzers and other sets of fields specific for the traffic analyzed by the corresponding protocol analyzer, e.g. HTTP fields and IP fields.
EDRs are usage records generated with information that is totally configurable by the operator, thus achieving a great flexibility, EDR flexibility is provided in two areas: EDR fields and EDR generation rules.
To facilitate integration, EDRs may use industry standards for their format, such as CSV and XML.
When integrating a data retention or lawful interception solution for IP services, there are some data retention sources or Intercepting Control Elements (ICEs) from which it is possible to retrieve information related to communications at different TCP/IP stack layers, by using packet inspection features.
A problem exists at the DR/LI Handover Interfaces with the data/interception requesting authority, because the communications exchanged through the Handover Interfaces relate to different TCP/IP stack layers. For instance, in the known DR systems which can retrieve information related to communications at different TCP/IP stack layers, the requesting LEA receives from the DR system retained data separately for each of the stack layers, e.g. retained data at the application layer (Layer 5), at the transport layer (Layer 4), at the network layer (Layer 3) and at the data link layer (Layer 2).
Similarly, in the known LI systems which can retrieve information related to communications at different TCP/IP stack layers, the LEA/LEMF can separately receive from the LI Mediation Function 2 IRIs containing application layer information, IRIs containing transport layer information, IRIs containing network layer and IRIs containing data link layer information.
In some cases, data from different communications stack layers may be collected from a plurality of different sources and it is not possible to correlate them. For instance, GPRS nodes may provide a private IP address which, through a NAT function, is translated into a public IP address which finally arrives at a Messaging Server. In such case, the IP addresses would not be enough for correlating the communications at different layers.
As a consequence, there is currently no possibility of correlating communications at different stack layers on the Handover Interfaces.